1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
hotspots can be investigated by the community since bobcat and sensecap are closed source
hotspots can be investigated by the community since bobcat and sensecap are closed source poc_interval however still not a guarantee of that interval. Since the challenger gets a list of all occupied hexes on the network and randomly picks one to target.
Current libp2p issues indeed have lead to degradation in regards to PoC however the purpose of this HIP should still exist. There’s built in wiggle room already to help in situations that are out of the operators hands. I think one may say it’s too generous as it’s currently written.
With the shift to light hotspots most of those p2p issues will disappear and it’ll become even more strict. But those who don’t setup correctly are still going to have issues.poc_interval however still not a guarantee of that interval. Since the challenger gets a list of all occupied hexes on the network and randomly picks one to target.
Current libp2p issues indeed have lead to degradation in regards to PoC however the purpose of this HIP should still exist. There’s built in wiggle room already to help in situations that are out of the operators hands. I think one may say it’s too generous as it’s currently written.
With the shift to light hotspots most of those p2p issues will disappear and it’ll become even more strict. But those who don’t setup correctly are still going to have issues.
6
1last_poc_challenge is tied to this action. Since you haven't created a challenge in such a long time you're technically not eligible for PoC (ie beacons). The question then lies, why? Usually you see challenges being created constantly with other activities flatlining. I've seen a miner_poc_statem loop before that prevents them from performing said actions which essentially boiled down to a sync issue.
TL;DR - You're going to need to do a diagnostics on the hotspot (local or remote) and check on the block sync status. The other thing is do a remote reboot of the hotspot and see if that'll "wake" it up.last_poc_challenge is tied to this action. Since you haven't created a challenge in such a long time you're technically not eligible for PoC (ie beacons). The question then lies, why? Usually you see challenges being created constantly with other activities flatlining. I've seen a miner_poc_statem loop before that prevents them from performing said actions which essentially boiled down to a sync issue.
TL;DR - You're going to need to do a diagnostics on the hotspot (local or remote) and check on the block sync status. The other thing is do a remote reboot of the hotspot and see if that'll "wake" it up. last_poc_challenge is used to determine eligibility to beacon. If his doesn’t create a challenge the blockchain assumes it’s inactive. Even if it’s witnessing. I can show you in the source code if you’d like (edited)last_poc_challenge is used to determine eligibility to beacon. If his doesn’t create a challenge the blockchain assumes it’s inactive. Even if it’s witnessing. I can show you in the source code if you’d like (edited)112iv4sfrCB5euAw5raCGUPzWWGGCYD3dZkXFa3zhMky4dusJwFP right?112iv4sfrCB5euAw5raCGUPzWWGGCYD3dZkXFa3zhMky4dusJwFP right? last_poc_challenge I was under the impression only updated when the poc_receipt was on the blockchain. But it appears it's attached to the poc_request ... with that being said it does appear that it's not being restricted by the last_poc_challenge like I had expected earlier... I guess the only next possible answer is if there's two hotspots sharing the same IP address maybe? And the blockchain is forwarding all requests to that one?
When it comes to his challenges - he should always get the beaconers poc_receipt as long as he's able to send it to the beaconer. Since that's how TCP connections work. Unless the challenger's connection times out before the poc_receipt is returned. So the fact he's able to create_challenges but the challengee can't return that receipt is ... well interesting.
If the following IP address is correct for the hotspot /ip4/75.83.206.202/tcp/44158 then that'd be the only explanation that I'd have. (edited)poc_request being accepted by the CG.. The miner then needs to pick up that approved transaction (ie finds it in a subsequent block) then it's able to actually create the challenge for the challengee. The (purple) one is the receipt that the beaconer received the request to beacon.
From what we know, there's multiple points of failure all hard to see unless you can view the console.log of the miner. 1) The miner can't see the approval (green) poc_request on a subsequent block 2) it see's the approval but can't dial out to the beaconer (possible if peerbook isn't up to date for challengee) but if it fails it "should" try again immediately. Three times before constructing a new challenge right away... right away as in within poc_interval.. 3) it's able to send it to the the challengee (beaconer) but the established TCP connection closes before the beaconer can return it's poc_receipt resulting in that challenge being dropped. But all of these issues don't have to deal with "it" being able to beacon itself.
Unless of course the above is now true for the hotspot that's trying to challenge his miner. (As in the rolls are flipped now)... therefore, either he's being blocked by the IP bloom filter (the IP is being used for two hotspots) or the challenger is having the same issues he's having on the sending challenges issue above... (edited)listen_addrs just the challenger needs to know the challengee -- wow this sentence sounded better in my head.. it's a loop of sorts (edited)listen_addrs just the challenger needs to know the challengee -- wow this sentence sounded better in my head.. it's a loop of sorts (edited)
4
2
4poc_challenge_interval which is now set at 360 versus the 240... With that being said the theoretical max is now 4. (edited)poc_challenge_interval which is now set at 360 versus the 240... With that being said the theoretical max is now 4. (edited)
5WITH witnessed_list AS (
SELECT witness_address, COUNT(transmitter_address) as witnessed
FROM challenge_receipts_parsed
WHERE block > (select min(height) from blocks where timestamp > now() - INTERVAL '5 DAYS') and witness_address = {{address}}
GROUP BY witness_address
)
SELECT c.transmitter_name, c.transmitter_address, COUNT(DISTINCT c.witness_address) as witnesses, w.witnessed, (COUNT(DISTINCT c.witness_address) * 6 * 2) as limit, (COUNT(DISTINCT c.witness_address) * 6 / 5 * 2) as daily_limit, w.witnessed > (COUNT(DISTINCT c.witness_address) * 6 * 2) as limited
FROM challenge_receipts_parsed as c
INNER JOIN witnessed_list as w
ON c.transmitter_address = w.witness_address
WHERE block > (select min(height) from blocks where timestamp > now() - INTERVAL '5 DAYS') and transmitter_address = {{address}}
GROUP BY transmitter_name, transmitter_address, w.witnessed;WITH witnessed_list AS (
SELECT witness_address, COUNT(transmitter_address) as witnessed
FROM challenge_receipts_parsed
WHERE block > (select min(height) from blocks where timestamp > now() - INTERVAL '5 DAYS') and witness_address = {{address}}
GROUP BY witness_address
)
SELECT c.transmitter_name, c.transmitter_address, COUNT(DISTINCT c.witness_address) as witnesses, w.witnessed, (COUNT(DISTINCT c.witness_address) * 6 * 2) as limit, (COUNT(DISTINCT c.witness_address) * 6 / 5 * 2) as daily_limit, w.witnessed > (COUNT(DISTINCT c.witness_address) * 6 * 2) as limited
FROM challenge_receipts_parsed as c
INNER JOIN witnessed_list as w
ON c.transmitter_address = w.witness_address
WHERE block > (select min(height) from blocks where timestamp > now() - INTERVAL '5 DAYS') and transmitter_address = {{address}}
GROUP BY transmitter_name, transmitter_address, w.witnessed;
1
1
1witness_limit_cap a daily limit?Should hotspots be rewarded for simply being in a "good" location where they have the ability to hear 100's if not 1000's of other hotspots? I argue that's these areas are too redudant and shouldn't be rewarded simply for witnessing.. hence this proposal
I also disagree with this sentiment - places that have great coverage provide more valuable per-hotspot coverage than others and (I feel) should be rewarded as such. Scaling already takes care of the redundancy point (or should) (edited)poc_challenge_interval and poc_per_hop_max_witnesses chain variables... the current #1 hotspot only see's 536 witness rewards per day right now and the #1 hotspot with beacon witnesses have 165 unique witnesses..poc_challenge_interval and poc_per_hop_max_witnesses chain variables... the current #1 hotspot only see's 536 witness rewards per day right now and the #1 hotspot with beacon witnesses have 165 unique witnesses..
1
1
1
1
1poc_challenge_interval is 576 (edited)
1
1
1
2
1
1
1
2
1
5
1
1
2
3

Reason: Posting NSFW Websitescompensation_factor will make sure you're not affected
1
1
1
1
2
1
1
1
1
1
14 based on the IP bloom filter in place and that it gets reset every poc_challenge_interval which is currently set at 360 blocks. On the other side, there isn't a minimum amount of beacons a day a hotspot is restricted by the network either. Meaning that we can only see what an average hotspot can expect to receive based on a network average which is currently 2.4 which is where the compensation factor comes from as stated in the HIP.4 based on the IP bloom filter in place and that it gets reset every poc_challenge_interval which is currently set at 360 blocks. On the other side, there isn't a minimum amount of beacons a day a hotspot is restricted by the network either. Meaning that we can only see what an average hotspot can expect to receive based on a network average which is currently 2.4 which is where the compensation factor comes from as stated in the HIP.
1
3
1
1
1
1poc_challenge_interval the beaconer doesn't have control over requesting a beacon because of what you said with custom firmware. Also, if you know the MD5 checksum you could simply send that to the checksum service. It's open sourced so you could easily figure out the required MD5 checksum needed (edited)poc_challenge_interval the beaconer doesn't have control over requesting a beacon because of what you said with custom firmware. Also, if you know the MD5 checksum you could simply send that to the checksum service. It's open sourced so you could easily figure out the required MD5 checksum needed (edited)

1poc_challenge_interval is how often your hotspot tries to create a challenge. There's multiple reasons why one might miss this window but it's a check performed every block so eventually it'll create a challenge after those many blocks. This however, isn't saying that your hotspot will beacon at this interval. "If you had two hotspots on the network and they both try to create challenges at this interval then they should also beacon at that interval." It's a proxy since there's no guaranteed minimum beacon number. There is however a max 4 that's based on an IP bloom filter and an average based on the data on chain 2.4 (edited)poc_challenge_interval is how often your hotspot tries to create a challenge. There's multiple reasons why one might miss this window but it's a check performed every block so eventually it'll create a challenge after those many blocks. This however, isn't saying that your hotspot will beacon at this interval. "If you had two hotspots on the network and they both try to create challenges at this interval then they should also beacon at that interval." It's a proxy since there's no guaranteed minimum beacon number. There is however a max 4 that's based on an IP bloom filter and an average based on the data on chain 2.4 (edited)
12022-01-26 20:15:21.254 1 [error] <0.4865.0>@libp2p_multistream:read:40 CRASH REPORT Process <0.4865.0> with 0 neighbours crashed with reason: no match of right hand value {error,{missing_terminator,<<"ET /db/manage/ HTTP/1.1\r\nHost: my.ip.address.lol:7474\r\nUser-Agent: Mozilla/">>}} in libp2p_multistream:read/2 line 40 (edited)ok = blockchain_ledger_v1:commit_context(AuxLedger1); (edited)poc_challenge_interval has changed…
1
2
#hip-42-beacon-witness-ratio-witness-reward-limit has been locked!